Portions of this patent application contain material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document, or the patent disclosure, as it appears in the Patent and Trademark Office. All other rights are expressly reserved.
This invention relates to the configuration of computer systems and, more particularly, to an object-oriented apparatus and a method for assigning computer system resources to a plurality of I/O devices coupled to the computer system while avoiding conflicts among the devices for the resources.
A typical computer system is comprised of a variety of interconnected computer hardware components and devices. The terms xe2x80x9ccomputer hardware components,xe2x80x9d xe2x80x9chardware components,xe2x80x9d xe2x80x9cperipheral devicesxe2x80x9d or simply xe2x80x9cdevicesxe2x80x9d all refer to individual electronic devices which are coupled together to provide the computer system. For example, the computer keyboard, mouse, monitor, printer, hard disk drives, floppy disk drives, memory boards and the like constitute such devices. Many of these components are mounted on a printed circuit board generally referred to as a xe2x80x9cplanarxe2x80x9d or a xe2x80x9cmotherboard.xe2x80x9d
In many conventional architectures, the various components are connected together by means of a system bus which defines a medium over which information is transferred between the components. The system bus typically includes data, address and control lines which carry data, address and control information between the various system components. For example, an interrupt signal may be sent from one or more of the peripheral devices over the control lines of the system bus to the processor.
The system bus and some basic hardware components connected to the system bus form an integrated system which is generally contained on the motherboard. In many personal computer systems, the system bus is connected to an extension called an xe2x80x9cexpansionxe2x80x9d bus and the motherboard typically has one or more slots or connectors on the expansion bus, which connectors are referred to as xe2x80x9cexpansion slotsxe2x80x9d or xe2x80x9cexpansion connectors.xe2x80x9d
To enhance the performance of the computer system, additional hardware components on printed circuit boards referred to as xe2x80x9cdevice expansion boardsxe2x80x9d, xe2x80x9cdevice expansion cardsxe2x80x9d, xe2x80x9cexpansion boardsxe2x80x9d or xe2x80x9cexpansion cardsxe2x80x9d can be plugged into the expansion slots. Depending upon the particular architecture of the computer system bus, an expansion card may constitute a bus adapter which has its own bus and slots. Other expansion cards can then be plugged into these latter slots.
Expansion cards are generally coupled to a computer system to enhance the capabilities or performance of the computer system. For example, one type of expansion card is a memory expansion card which may be used to increase the amount of random access memory (RAM) available for use by the processor of the computer system. Other expansion cards include sound cards, SCSI bus adapters, graphics accelerator cards and others.
Many expansion cards can be customized or configured by setting the values of one or more parameters. In some cards, the values are set manually by changing jumpers of switches located on the boards. In other cases, the parameters are set either manually or automatically by software. More particularly, the computer system is typically controlled and coordinated by a software program called a computer operating system (e.g. MS-DOS, OS/2, etc . . . ). Each device connected to the system bus interacts with the computer operating system through another software routine called a device driver. The device driver receives commands from the operating system and uses the commands to control the device.
In the case where device parameters are set by software, the device driver can often access the device parameters which parameters may be stored in the device itself, in the computer memory or in other portions of the computer system. The device parameters can then be set manually through the device driver software. In other cases, the device parameters are set automatically be means of configuration software which interacts with the driver software.
Device drivers are provided as part of the computer operating system software for devices which are typically found in a conventional computer system. For example, operating system software typically includes device drivers for the computer keyboard, monitor, hard and floppy disk drives, and communication ports. Since there are so many different I/O expansion device configurations, these devices have device-specific device drivers which typically are not provided as part of the operating system software, but instead are stored as separate files. Such individual device drivers are generally referred to as installable device drivers since they must be explicitly installed in the system memory before the associated device can be used.
For example, in a computer which executes the MS-DOS operating system, an installation command for a particular installable device driver could be added to a boot file named xe2x80x9cconfig.sysxe2x80x9d which file is stored in a memory of the computer. When the computer processor initially begins executing the MS-DOS operating system, the processor executes the commands contained in the config.sys file. When device driver commands are included in this file, the processor executes the installation command for the installable device driver which loads the installable device driver into memory thereby providing access to the device. Alternatively, an application program which needs access to the device could load the driver during its initialization phase.
In addition to physically inserting an expansion card, installing the device driver and setting device parameters, in many cases it is also necessary to allocate computer resources to the expansion card. The term xe2x80x9ccomputer resourcexe2x80x9d or more simply xe2x80x9cresourcexe2x80x9d refers to anything within a computer system which either occupies memory of the computer system or which is required to allow the computer system to perform a particular function. To print a page of a document, for example, certain resources such as character font sets, glyph sets, point tables, brush tables, user defined graphic images and data that describes a page to be printed may be required to perform a print function. Thus, such resources may be referred to as printer resources.
Expansion cards also provide I/O functions to the computer system. An I/O function is provided by a discrete device that is independently assigned I/O resources. Examples of I/O Functions are, Serial Port, SCSI port, Floppy, etc. I/O functions require I/O resources, which include, but are not limited to, computer memory space, I/O registers, interrupt signal lines, interrupt levels, interrupt sockets, direct memory access (DMA) channels, etc., which allow the I/O hardware components to operate with the computer system. Generally, the term I/O function is used in the discussion which follows rather than I/O device, since a single physical device or card may have several I/O functions implemented on it. Consequently, a function corresponds to a logical device rather than a physical device.
The computer resources are often allocated to the I/O expansion boards in the same manner as hardware component parameters are set. For example, in some cases, resources can be allocated or selected manually, while in other cases, automatic configuration software allocates the resources.
More specifically, many personal computers utilize a system bus architecture referred to as the industry standard architecture (ISA) bus architecture. The ISA bus architecture has been implemented in a very large number of IBM and IBM-compatible personal computers. Computers employing the ISA bus architecture require the allocation of system resources such as memory, I/O address spaces, direct memory access (DMA) channels, interrupt request lines and interrupt levels among multiple ISA expansion cards in the system.
The types of expansion cards which may be used in computer systems having an ISA architecture may be divided into the following six categories: (1) manually-configured ISA cards; (2) manually-configured motherboard devices; (3) manually-configured local bus cards; (4) auto-configuration ISA cards; (5) peripheral component interconnect (PCI) cards; and (6) PCMCIA cards. Auto-configuration ISA cards include mechanisms for card identification, resource usage determination, conflict detection and conflict resolution. This capability allows compatible operating system software to automatically identify and configure auto-configuration ISA cards without manual user intervention.
The conventional ISA standard, however, does not define any hardware or software mechanism for allocating system resources. Thus, expansion cards and motherboard devices which conform to the ISA standard may not include any on-board mechanisms for card identification, resource usage determination, conflict detection or conflict resolution. This can lead to problems in assignment of system resources.
For example, depending upon the particular operating system (e.g. MS-DOS, WINDOWS, OS/2, WINDOWS 95 etc . . . ) controlling the computer, it may be necessary to assign an interrupt line to a particular device. Often, each device requires a unique interrupt line. For example, a serial communication board installed on a computer operating with a WINDOWS(trademark) graphical user interface must have a unique interrupt line coupled thereto. That is, no other device which is operating simultaneously can have the same interrupt line assigned to it.
In conventional systems, a user must examine the configuration of each installed device to determine which, if any, interrupt line each device is using and which interrupt lines are unused. The user then selects an unused interrupt line to couple to the serial communication board. The selection of the interrupt line may be implemented on the ISA card manually by connecting so-called jumper wires (or more simply jumpers), opening or closing particular terminals of dual in-line pin (DIP) switches which are located on the expansion cards, or via the device driver. Thus, a user must devote a relatively large amount of time to configuring a conventional ISA card.
In addition to the above, the configuration files of the computer system may also need to be updated to allow the computer system to recognize that an additional device has been added to the computer system. When a problem does arise, users typically must manually resolve resource allocations by referring to documentation provided by the manufacturer of the expansion card involved in the resource allocation.
A problem, referred to as a resource conflict, can arise however, if two or more devices simultaneously attempt to use the same computer system resource, such as the same, or overlapping, memory regions of the same memory device. When such a resource conflict occurs, one or more of the devices involved in the conflict may not operate correctly or the computer system may not operate correctly or may even stop operating altogether (i.e., the computer system becomes xe2x80x9chung-upxe2x80x9d). This problem is particularly acute when resources must be manually allocated. In this latter case, the user may be unsophisticated and not able to properly allocate resources. Many computer systems come preconfigured with I/O devices such as a mouse, communication ports, etc. and resources are already allocated when the user receives the system. In these cases, it may be difficult for the user to ascertain which resources are already allocated even if the user is sophisticated enough to allocate resources.
In order to assist the user in manually selecting free resources, some expansion cards come with resource checking programs that attempt to determine which resources are already in use. These programs are run before a user physically inserts an expansion card and generally identify resources which are not in use and which would satisfy the requirements of the card. One problem which arises with such programs is that, often, the resources are not in use when the checking program is run because the card which uses the resources is not active. Therefore, a resource shows up as free, when it is not. Later, when all cards are active, a resource conflict occurs.
In conventional computer systems, when a resource conflict arises, a user must ascertain the cause of the resource conflict by determining which computer system resource is being accessed by each device and which devices are attempting to access the same resource. Once the user has ascertained the cause of the resource conflict, the user must then devise a plan to resolve the resource conflict. This is often a time consuming effort, since the user must determine which computer resources each device in the computer system uses, often by trial and error, and then reassign available computer resources to devices involved in the resource conflict.
In addition to ISA cards, some computer systems employing an ISA architecture are provided having expansion slots which handle additional bus architectures. For example, some expansion slots are referred to as local bus slots and accommodate a xe2x80x9clocal busxe2x80x9d card. Local bus slots typically accept expansion cards such as video adapter cards or mass storage cards. Cards conforming to this architecture have an internal bus structure that allows information to be transferred between components on the card without involving the system bus. Use of the internal local bus improves the performance of the computer system. Generally, computer systems employing the ISA architecture can operate with a variety of local bus architectures including but not limited to the video electronics standards association (VESA) bus architecture. However, many of the local bus architectures do not include any mechanism for identification and automatic configuration of the cards plugged into their slots. That is, many expansion cards employing local bus architecture cards are not auto-configuration expansion cards.
Rather, such local bus cards are typically configured manually by connecting jumper wires and setting DIP switches, as is done with expansion cards which conform to the conventional ISA standard. Since conventional ISA cards and manually-configured local bus cards are configured in the same manner, these types of cards will collectively be referred to herein as xe2x80x9cmanual I/O expansion cardsxe2x80x9d or xe2x80x9cmanually-configured I/O expansion cards.xe2x80x9d
One local bus architecture referred to as a Peripheral Component Interconnect (PCI) architecture accepts expansion cards which conform to a PCI standard. Expansion cards which conform to the PCI standard are auto-configurable in that they include mechanisms for card identification and resource usage determination.
In addition in some computers, a motherboard may be provided having a socket which accepts an expansion card that conforms to a PCMCIA standard. Expansion cards conforming to the PCMCIA standard can be inserted into a system still having power applied thereto (i.e. the computer system need not be turned off while the PCMCIA expansion card is coupled to the computer). Furthermore, expansion cards conforming to a PCMCIA standard can be configured with software rather than via jumper wires and DIP switches. Thus, computer systems which only include expansion cards which conform to either the auto-configurable ISA, PCI or PCMCIA standards are fully auto-configurable.
Some computer systems, however, include expansion cards which conform to the manually-configured ISA and local bus standards as well as expansion cards which conform to the auto-configurable ISA, PCI or PCMCIA standards. Thus, such computer systems require some user intervention in configuring the manually-configured I/O expansion cards.
Computer systems which accept manually-configured I/O expansion cards require some mechanism to specify to the operating system software the configuration information for such expansion cards. Certain manually-configured expansion cards may be identified by device-specific probing techniques. That is, configuration information of the expansion card may be determined by reading and writing to device specific hardware ports of the expansion card. However, such probing techniques are not always reliable. Furthermore, some expansion cards are not compatible with probing techniques. Thus, conventional techniques for configuring devices in computer systems having an ISA bus architecture either use a configuration file in memory to specify the resource assignment information or hard code the resource assignment information into the corresponding device drivers.
In the case of expansion boards which incorporate an additional bus architecture, a program called a resource manager is used to store and manage the configuration and resource allocation information for the devices plugged into the additional bus. A problem arises, however, in that, in conventional systems, a separate resource manager is used for each different type of expansion bus. For example, in a computer system having both a Peripheral Component Interconnect (PCI) bus and a Personal Computer Memory Card Interface Association (PCMCIA) bus, the resources used by the PCI expansion card and the resources used by PCMCIA expansion card would be managed by separate resource managers located on each expansion card. These separate resource managers typically do not share information and thus neither resource manager contains any information as to which resources the other resource manager is using, leading to possible resource conflicts.
It would, therefore, be desirable to provide a system which automatically detects and resolves resource conflicts between two or more devices in the computer system. Such resource conflicts may occur, for example, between two devices coupled to the motherboard via an expansion card or between a device on the motherboard and a device on an expansion card.
In accordance with the present invention, system resources are automatically assigned by a resource conflict resolver to all functions on expansion buses in the computer system. Such system resources include, but are not limited to, memory ranges, input-output (I/O) register ranges, interrupt request lines and direct memory access (DMA) channels. Generally, the assignment is exclusive, however, in some cases, the assignment may be shared so that one or more resources will be shared between different functions. In order to prevent contention between two functions for the same resource, the inventive conflict resolver framework includes classes which can be instantiated to construct objects that provide an access control mechanism to synchronize access to the resources among the devices that use and, possibly, share them.
Specifically, the resource conflict resolver generates conflict free resource assignments and stores these assignments in resource usage objects in a persistent hardware configuration database. The inventive I/O framework provides classes from which a lock object can be instantiated. The lock object contains methods which retrieve the resource assignments for an I/O function from the resource usage objects and methods which acquire a lock on resources assigned to an I/O function. The lock object can be used by device drivers to first retrieve the resource assignments from the hardware configuration database and then acquire access to the resources assigned to an I/O function. The acquired access can be either exclusive or shared.
In order to access the resources for an I/O function, clients instantiate a lock entry object from a framework resource lock entry class and call the Acquire( ) method of the object. The lock entry object also includes a method which retrieves a conflict-free resource assignment for an I/O function from the corresponding resource usage objects in the hardware configuration database. The method which retrieves the resource assignment can be called after the resource lock is acquired by means of the Acquire( ) method. The resources can be used only by the task which calls the Acquire( ) method or by interrupt handlers which have been registered in the I/O resource conflict resolver.